Optimize hash_table_locks #618
Conversation
|
Hi, thank you for submitting this pull request. In order to consider your code we need you to sign the Oracle Contribution Agreement (OCA). Please review the details and follow the instructions at https://oca.opensource.oracle.com/ |
|
I have submitted the Oracle Contributor Agreement (OCA), it's under review now, but I have no idea when this can be approved |
|
Hi, @ALL! |
|
Hi, thank you for your contribution. Please confirm this code is submitted under the terms of the OCA (Oracle's Contribution Agreement) you have previously signed by cutting and pasting the following text as a comment: |
|
I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it. |
|
Hi, thank you for your contribution. Your code has been assigned to an internal queue. Please follow |
Analysis
Under high throughput, a hotspot caused by
rw_lock_s_lock_funccan be observed in MySQL, originating fromBuf_fetch_normal::get. The key call path is:buf_page_get_gen → Buf_fetch::single_page → Buf_fetch_normal::get.The function of
Buf_fetch_normal::getis to retrieve the pointer to a data block (i.e.,buf_block_t*) in the buffer pool for a target data page, which involves querying the buffer pool using (space_id, page_no) to read or write page content. This mapping relationship is maintained by a hash table called page_hash, protected byhash_table_locks. Therw_lock_s_lock_funchotspot arises from the read-lock operation on thesehash_table_locks.On the other hand, sharding the lock objects with fierce competition is a common optimization method. In MySQL source code,
hash_table_lockshas been optimized through sharding. The number of shards is controlled bysrv_n_page_hash_locks, but it is hard-coded to 16.Optimization